Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-185 < prev next >

Wrap

Text File | 1988-12-01 | 45.7 KB | 1,239 lines

IEN-185 INDRA Note 1101 May 26, 1981 DEVELOPMENT OF UK/US NETWORK SERVICES AT UNIVERSITY COLLEGE, LONDON Robert T. Braden Peter L. Higginson IEN-185 May 26, 1981 ABSTRACT: This document describes the second- generation service facility under development at UCL, to connect the DARPA Catenet with X25-based networks in the UK. The facilities will include a Terminal Protocol Converter, a Transport Service Gateway, and an "IP Tunnel". INDRA Note # 1101 Department of Computer Science University College, London CONTENTS 1. INTRODUCTION...........................................3 2. PROTOCOL CONSIDERATIONS................................5 2.1 Routing and Addressing.............................5 2.2 Protocol Conversion................................7 2.3 Cost Minimisation..................................8 2.4 Access Control.....................................8 3. SERVICE FACILITIES.....................................9 3.1 Terminal Service...................................9 3.2 File Transfer Traffic..............................10 3.3 MOD Services.......................................11 4. TERMINAL PROTOCOL CONVERTER............................15 5. CONCLUSIONS............................................19 6. REFERENCES.............................................20 [Page 1] UK/US Service at UCL IEN-185 1. INTRODUCTION This report describes the network interconnection facilities being developed at University College, London (UCL) to support US/UK collaborative research computing. Briefly, these facilities will link users and resources connected to the ARPA Catenet of the US Department of Defense with users and resources on several public and private networks in the UK. Terminal access to remote time-sharing systems, file transfer, and mail services are to be provided [1,2]. The facility to be described will be a "second generation" US/UK network interconnection at UCL, replacing a UK/ARPANET link established at UCL in 1974. UK users accessed the earlier service through SRCNET [3,15], a network operated by the Science Research Council; through EPSS [4], an experimental public data network; or by direct dial-in to a TIP at UCL. This service is now almost totally obsolete, as the networking worlds have changed markedly on both sides of the Atlantic. (1) Protocol Changes The ARPANET has been embedded in the "Catenet", i.e., a network of networks. To support host communication across the Catenet, the ARPANET host-to-host protocol "NCP" [5] has been replaced by an end-to-end protocol TCP, operating over an internetwork datagram protocol layer, IP [6,7]. On the other hand, the ARPANET higher- level terminal protocol Telnet and the file transfer protocol FTP have been kept essentially unchanged by the Catenet [5]. Meanwhile, the UK has generally adopted the CCITT- recommended X25 network-level protocol as well as the terminal access protocols X3, X28, X29 (commonly collected under the rubric "XXX" or "Triple-X") [8]. Furthermore, UK working groups have adopted a transport service, NITS [9,14] (known as "Yellow Book" from the colour of the document's cover), and a file transfer protocol, NIFTP [10] (known as "Blue Book"). Both are de facto UK standards and have been submitted to the international standards bodies CCITT and ISO. Thus, the UK has moved to adopt international standard protocols, all of which differ from the corresponding DARPA Catenet protocols. [Page 3] UK/US Service at UCL IEN-185 (2) Network Changes The DARPA Catenet includes the ARPANET, a number of local networks, and a satellite network SATNET [11]. In particular, SATNET links the US continental ARPANET with PPSN [13], a packet-switching network of the UK Ministry of Defense (MOD). The gateway between PPSN and SATNET, which is located at UCL, has local ports into SATNET which provide one of the paths for US/UK interconnection. Public data networks have become a reality both in the US and in the UK. In the US, "Valued-Added Networks" (VAN's) such as Telenet and Tymnet have come into existence. In the UK, the government-owned British Telecom has installed a public packet-switched network PSS [12]. PSS uses the standard protocols X25, X28, and X29. PSS users have agreed to use NITS, NIFTP, and an enhancement of X29 called TS29 (the "Green Book") [13]. PSS has created a set of de facto national protocol standards for the UK, and private data networks are likely to strive for compatibility with it. In particular, SRCNET has been moving towards almost complete compatibility with PSS protocols [15]. Finally, an international packet switching service, IPSS, now links the UK with the Value-Added networks in the US, Canada, and many other countries. In the UK, IPSS will shortly be linked to PSS. In the US, BBN is developing a "VAN Gateway" which will link the ARPANET to Telenet. Thus there will shortly be two paths linking UCL with the US ARPANET -- the X25-based public carrier facility of PSS/IPSS/VAN, and the private DARPA Catenet facility of SATNET. (3) New Administrative Requirements Public data networks have usage charges for their services. This in turn will force UCL to provide both access control and accounting for these services, and leads to cost minimisation considerations that have not been necessary previously. Furthermore, there are now at least two different classes of users for the internetwork services provided by UCL; these classes will see quite different kinds of services. The SATNET path to the US, which is available only to authorised DARPA Catenet users, has no usage-dependent charge. Both the MOD and British Telecom are concerned to [Page 4] UK/US Service at UCL IEN-185 limit the use of this route. Others in the UK must use the IPSS path, whose usage costs are very significant. The magnitude of the packet and connect charges on IPSS, together with the technology of SATNET, will force important changes in the mode of ARPANET use from the UK. (a) The character-at-a-time, server-echo mode of terminal use which is customary on most ARPANET hosts will be far too costly on the IPSS path. It will still be feasible (although somewhat awkward, because of long delays) on SATNET, but it makes very inefficient use of the limited channel capacity. (b) The ARPANET practice of effectively broadcasting mail, i.e., sending individual copies of the same message to all recipients, is uneconomic over IPSS. (c) Since file transfer is expected to make more cost- effective use of the channel than does terminal traffic, it will generally be cheaper for UK users to send and receive their ARPANET mail in the UK, transferring it across IPSS only in bulk. This implies that UCL should provide a service host for receiving and composing mail. 2. PROTOCOL CONSIDERATIONS The preceding section described the current environment for the network interconnection facilities under development at UCL. This section covers the communication protocol issues relevant to the design of these facilities. Later sections will give more details of the software and hardware required. In general, two entirely different protocol domains are being linked -- the CCITT/public data network world of X25, XXX, NITS, and NIFTP, and the DARPA internetwork world of IP, TCP, Telnet, and FTP. There are several different types of problems, which will be considered in turn: divergent mechanisms for handling routing and addressing, protocol conversions, cost, and access- control. 2.1 Routing and Addressing To design the interconnection facility, we need to identify those protocols that provide (essentially) the same functionality, [Page 5] UK/US Service at UCL IEN-185 i.e., which occupy the same "protocol layer". We will use the following terminology: (a) Network Layer The network layer provides reliable, ordered transmission across virtual circuits spanning a single address domain. (b) Transport Layer The transport provides the same services of the network layer, and in addition provides them end-to-end across multiple address domains. (c) User Layer We use this term for all protocols "above" the transport layer, for example terminal and file transfer protocols. To indicate the relative position of two protocols in the heierarchy, we will use the notation: A > B for (higher-level) protocol "A" implemented "over" protocol "B". Obviously Telnet, XXX, NIFTP, and FTP occupy the user layer as defined here. Furthermore, by definition NITS occupies the transport layer. However, TCP and X25 may each be assigned to either the transport or the network layer, depending upon the situation. For example, the public data networks use a uniform, globally- unique set of 14-digit addresses, and therefore form a single address domain. The gateways between public data networks also provide a routing mechanism. As a result, "bare" X25 can be used as a transport service over a single network or across interconnected public data networks (e.g., U.S. VAN to IPSS to PSS). However, private UK networks (e.g., SRCNET) constitute different address domains. An X25 virtual call whose two ends lie in different address domains requires a transport service to specify the addressing and routing for setting up concatenated virtual calls. NITS (Network Independent Transport Service) [9] provides a general source-route addressing facility to handle such multiple address domains. NITS is then the transport service, and X25 is demoted to the network layer. NITS allows multiple independent address domains, but provides no global routing or addressing mechanism. Routing decisions are [Page 6] UK/US Service at UCL IEN-185 assumed to be sufficiently static that they can be built into tables in the originating host and in intermediate gateways. The DARPA internet protocol, on the other hand, assumes a single global addressing domain and dynamic routing implemented by cooperating gateways. Addresses are limited to 32-bit numbers. The protocol combination "TCP > IP", used within its "home" Catenet, constitutes a transport service. However, TCP > IP fails to provide general end-to-end addressing between a Catenet host and an X25 host, since TCP > IP cannot specify X25-domain addresses. One solution to this problem of end-to-end addressing has been proposed for the BBN VAN gateway [24]: the gateway will contain a fixed table to map X25 addresses to and from "fake" internet addresses. To simplify maintenance of this and other equivalent tables, it may be desirable for the gateway to do the address mapping by referencing a "Name Server", available to all relevant gateways. Another type of solution is provided by Bennett's proposal [18] for a true transport service protocol, based on NITS, to be used above TCP/IP. In practice, a combination of these techniques may be used. Finally, we can solve the addressing problem for terminal users by forcing them to interact with each gateway between address domains to specify the target address in the new domain. This was the solution in the UK/US service being replaced. 2.2 Protocol Conversion Both paths between the US and UCL will carry DARPA Catenet protocols, using TCP > IP. Over the VAN/IPSS/PSS route, IP datagrams will be encapsulated in X25 packets; this is sometimes referred to as an "internet tunnel" or "IP tunnel". The BBN VAN Gateway will form the Catenet end of such an IP tunnel. Since Catenet protocols are being brought to the UK, the conversion facilities must in general be in the UK; in particular, they will be at UCL. For interactive terminal service, the protocols used on the Catenet and the UK sides of the gateway differ at both the transport level and the user level. Thus, the ARPANET uses Telnet > TCP while XXX > X25 (or TS29 > NITS > X25) will be used in the UK. In addition, SRCNET uses a private terminal protocol called ITP [15], in the hierarchy: ITP > NITS(subset) > X25. [Page 7] UK/US Service at UCL IEN-185 Therefore, UCL must provide a "terminal gateway", i.e., a gateway which operates at the terminal protocol level. This facility will terminate each of the terminal protocols, transforming one protocol into another. We refer to this protocol conversion gateway as the "Terminal Protocol Converter". 2.3 Cost Minimisation The encapsulation of IP datagrams over the VAN, IPSS and PSS public data networks raises some difficult problems [23]. First, it is essential to minimise usage cost on these networks, particularly on IPSS. Since IPSS calls accumulate both connect- time and packet charges, cost can be reduced by multiplexing all the encapsulated traffic over a single virtual call; this call should be open only when the path is in use. It is not clear whether it will be worthwhile to pack multiple internet datagrams into a single X25 packet. PSS and IPSS charges are based on a data unit of 64 bytes; at most two small TCP packets would fit into a single unit, so the average lost due to internal fragmentation is roughly equivalent to one small TCP packet. Hence, packing datagrams will save less than a factor of 2 in cost. As an end-to-end protocol, TCP raises some very great difficulties with controlling cost inflation due to unwise retransmissions [24]. 2.4 Access Control The use of an IP tunnel through public data networks raises an urgent access control problem [23], again because of usage charges. At the UCL end of the IP tunnel, the Terminal Protocol Converter will require UK users to log in before opening a virtual call over PSS/IPSS. This log in will provide positive identification to check authorization and record usage. However, the "BBN VAN Gateway", at the US end of the tunnel, is planned as a pure internet datagram gateway [24]. This implies that it will be able to apply access control only on the basis of the source and destination internet addresses and the VAN address (of UCL). For example, it will contain a list of "authorised" Catenet hosts which are allowed to send packets to UCL through the VAN. Clearly, such a low-level mechanism cannot limit access to specific users or record user costs. [Page 8] UK/US Service at UCL IEN-185 3. SERVICE FACILITIES This section will describe the network interconnection facilities under development at UCL. These facilities will handle two major types of traffic -- interactive terminals and file transfer -- which pose different problems. 3.1 Terminal Service Figure 1 shows schematically the terminal service operation for those users required to use IPSS. The Terminal Protocol Converter must implement a command language, reached by an appropriate escape sequence. This language will include a "login" command and a "connect" command. The "connect" command will specify the address in the destination domain. The Protocol Converter must enforce user login, because the use of PSS or IPSS will result in the expenditure of UCL funds. This will solve UCL's access control problem for terminal service, and allow the proper recording of usage. Since the terminal protocols on the two sides differ quite significantly in facilities, fully-automatic conversion of terminal protocols is not possible [22]. The command language must allow the user to modify the conversion or to override it in a particular case. We can give a simple example of the need for user control over conversion. ARPANET hosts typically use Telnet negotiation to cause character echoing at the host end rather than the terminal end of the connection. Our Terminal Protocol Converter could easily translate "WILL ECHO" from the Catenet automatically into the equivalent in ITP or XXX. However, the use of host echo mode seriously increases IPSS costs, and cannot be dictated by the hosts. The Protocol Converter will therefore refuse the remote- echo negotiation, but will provide a command (available to authorised users) to allow host echo. Access to the UNIX system shown in Figure 1 will be primarily (and perhaps excusively) for UK users to compose and read mail. Bulk movement of mail files between this UNIX system and the US will be performed by NIFTP, as shown later (Figure 2). From the DARPA Catenet viewpoint, the Terminal Protocol Converter will terminate the IP, TCP and Telnet protocol layers; it therefore will be addressed as an internet host. Between the BBN VAN Gateway and the UCL facility labelled "IP Tunnel", internet datagrams will be transported over the public data networks (VAN, IPSS and PSS) by encapsulation in X25 packets. The "IP Tunnel" [Page 9] UK/US Service at UCL IEN-185 will perform this encapsulation, but we do not plan to make it a gateway; that is, it will not perform routing functions or implement GGP. Notice that PSS appears twice in Figure 1 -- as the link to IPSS, transporting encapsulated internet datagrams to the US, and also for terminal access to UCL from UK users. This is an indication the data paths on this diagram are logical; in fact, there will initially be only one physical path (line) to PSS from UCL. 3.2 File Transfer Traffic NIFTP [10] will be used for the transfer of files and bulk mail between the DARPA Catenet and the UK. This requires the use of suitable relays for file and mail transfer in the US. UCL has therefore created an NIFTP implementation on a TOPS-20 machine (ISIE), using either NCP or TCP as its transport service [17]. We plan to implement an automatic file transfer relay at ISIE, based upon this implementation. A mail relay is also being planned [16], to interface to the ARPANET mail service. Although the same user-level protocol, NIFTP, is used throughout, there will be different transport-level protocols on the UK and the Catenet sides. For file transfer, therefore, UCL need only provide a gateway operating at the transport service level, essentially independent of the user-level protocol on top. On the UK side, the transport service will be NITS > X25. On the Catenet side, a true transport protocol with end-to-end addressing is needed, since the X25 call is to be "concatenated" with the TCP connection. As discussed previously, "bare" TCP is not capable of transmitting the required X25 address. We therefore plan to adopt Bennett's proposal [18] for (a simple subset of) NITS above TCP. As shown in Figure 2, therefore, file transfers from the US across IPSS will use the (incredible) protocol hierarchy: NIFTP > NITS > TCP > IP > X25 Figure 2, which shows schematically the file tranfer paths seen by users who are are required to use IPSS, is topologically very similar to Figure 1. Instead of the Terminal Protocol Converter, Figure 2 has a Transport Service Gateway. The Transport Service Gateway does create a new access control and accounting problem. The NIFTP initiating the call should [Page 10] UK/US Service at UCL IEN-185 "log in" at the Transport Service Gateway, but NIFTP has no mechanism for such a log in. We plan to use the SRCNET solution for this problem [20] -- the necessary login information will be buried at the appropriate point in the NITS address string, to be interpreted by the Transport Service Gateway. 3.3 MOD Services Finally, Figure 3 shows the service facility as seen by the MOD users. The two datagram gateways shown in this diagram are both in service, maintained and controlled by BBN. Most of the paths shown on this diagram are part of the internet catenet. The "IP tunnel" is used here to provide an alternate route to PPSN. In these diagrams, we have generally omitted PSTN access for terminals. However, UCL will have a TAC to provide such access for the MOD. In addition, MOD users are expected to access UCL via a PSS PAD using X25. The UNIX system for mail services will be a PDP-11/34 initially, but might be upgraded in the future to a PDP-11/44. This machine will also be used to monitor and control the service functions, to accumulate accounting data, and to maintain the login data base. The function labeled "UCL Datagram Gateway" in Figure 3 is a PDP 11/35 running BBN's gateway code. All the other UCL interconnection functions will be implemented within LSI/11's running under MOS, using code written mostly in "C". [Page 11] UK/US Service at UCL IEN-185 FIGURE 1. VIEW OF UK/US SERVICE FOR SRC TERMINAL USER ///////// // // /////// /////// /////// // C // _____ // // // // // // // D a // | | // // ___ // I // ___ // // // A t // | BBN | // V // | | // P // | | // P // // R e //---| VAN |---// A //--| G |--// S //--| G |--// S //--- // P n // | Gwy | // N // |___| // S // |___| // S // | // A e // |_____| // // // // // // | // t // /////// /////// // // | // // /////// | ///////// | | | Telnet > TCP > IP > X25 | ____________________________________________________________| | | /////// ..|........................................... // // . | . // // . | U C L . XXX > X25 // P // . | . ____________ // S // . | ________________ . | // S // . | ______ | | . | // // . | | | Telnet > | |-------- // // . | | IP | TCP > IP | Terminal | . /////// . --| |----------| Protocol | . . |Tunnel| | Converter | . . |______| | |-------- /////// . | | . | ITP > X25 // // . |________________| . | and // S // . | Front | . | XXX > X25 // R // . | End | . |____________ // C // . |_______| . // N // . | . // E // . | . // T // . | . // // . (terminal access for | . /////// . msg service) | . . ==================== . . || || . . || || . . || U N I X || . . || || . . || || . . ==================== . .............................................. [Page 12] UK/US Service at UCL IEN-185 FIGURE 2. VIEW OF US/UK NIFTP SERVICE FOR SRC USERS To: PSS-IPSS-VAN-DARPA Catenet (see Fig. 1) ^ | | | NITS > TCP > IP > X25 | /////// | // // | // // ..|............................................. // P // . | . __________ // S // . | . | // S // . | ______ ______________ . | // // . | | | NITS > | |NITS > X25 | // // . | | IP | TCP > IP | Transport |----------- /////// . ---| |----------| Service | . . |Tunnel| | Gateway |----------- . |______| | |NITS > X25 | /////// . |______________| . | // // . | . | // S // . | . | // R // . | . |__________ // C // . | . // N // . (local | . // E // . transport| . // T // . service) | . // // . | . /////// . | . . =========|========== . . || U N |I X || . . || | || . . || _____|______ || . . || | NIFTP | || . . || | / mailer | || . . || |____________| || . . || || . . ==================== . ................................................ [Page 13] UK/US Service at UCL IEN-185 FIGURE 3. VIEW OF US/UK CONNECTIONS FOR MOD ///////// /////// // A C // ______ // S // // R a // | | // A // // P t // | Data-| // T // // A e //---------| gram |----------// N //------ // n // | Gwy | // E // | // e // |______| // T // | // t // /////// | ///////// | TCP > IP | ________________________________________________| /////// | // // | ........................................................ // P // | . . // P // | . ---------------------------------------------------- // S // | . | IP . // N // | . | _________ . // // | . _______ IP | "IP | . /////// | . | UCL |-------------------------------| Tunnel"| . IP ___|___ | . | Data- | TCP > IP |_________| . | MOD | -----| gram |-------------------------- | . | VAN | . | Gate- | _____|_____ | . | Gwy | . | way | TCP > IP | | | . |_______| . |_______|------> (IMP | Transport | | . IP >|X25 . | +TAC) | Service | | . | . | | Gateway | | . /////// . | _______________ |___________| |________ // // . | | | | IP > X25 // // . | | UCL | | . // P // . ----| Terminal |------------------------------- // S // .Telnet > | Protocol | | XXX > X25 // S // . TCP > IP | Converter | | . // // . |_______________| | . // // . | F.E.| | . /////// . |_____| | . . |___________ | (file . . | | transfer) . . (terminal access for | | . . msg service) =========|========== . . || U N |I X || . . || | || . . || _____|______ || . . || | NIFTP | || . . || | / mailer | || . . U C L || |____________| || . . ==================== . ........................................................ [Page 14] UK/US Service at UCL IEN-185 4. TERMINAL PROTOCOL CONVERTER In order to summarize the conversions to be performed by the Protocol Converter, we introduce the symbol "<==>" to mean "conversion to/from". For example, TCP < Telnet <==> ITP > X25 indicates that the terminal protocol Telnet operating "over" the transport protocol TCP is to be converted into the terminal protocol ITP operating over the transport service X25. The two primary conversions to be performed are: (1) TCP < Telnet <==> ITP > X25 (2) TCP < Telnet <==> XXX > X25 As mentioned earlier, we want to incorporate access to a UNIX system as a server. It is convenient to consider the UNIX server as a new protocol, and add the pseudo-conversions: (3) TCP < Telnet <==> UNIX (4) UNIX <==> XXX > X25 (5) UNIX <==> ITP > X25 Finally, we will add a terminal user process which will allow us to access each of the other four terminal protocol modules for testing. We call this terminal user process "TTY" and add the pseudo-transformations: (6) TCP < Telnet <==> TTY (7) TTY <==> ITP > X25 (8) TTY <==> XXX > X25 (9) TTY <==> UNIX You will note that we have listed all but one of the ten different conversions possible with the five protocols or pseudo-protocols. That omission is: (10) X25 < XXX <==> ITP > X25 Someone will probably find a use for this conversion, although it would not be related to US-UK service. [Page 15] UK/US Service at UCL IEN-185 FIGURE 4. TERMINAL PROTOCOL CONVERTER __________________________________________________________ | | | _______________ | | | | | | | ____________________ | | | | | | | | | | I | | | | | | | T |<=============>| T | | | | | | T | E | | P | X | | | | I | | L | ======>| | | | --------| | C | N | | |_______| 2 |-------- | | P | | E | | | | | | | | | P | T |<=============>| | 5 | | | | | | |<=== | | X | | | | |_____|_______|______| | | | X | | | | | | ===>| X | | | | | | | | | | | | | | | |_______|_______| | | ___|__|__|__ | | | | | |________________________| UNIX |____________________| | Terminal | | Front End | |____________| | | The Terminal Protocol Converter is implemented as a set of "Protocol Processes", one for each terminal-level protocol, and a common User Command Decoder Process. Each Protocol Process (PP) executes an appropriate terminal protocol module (Telnet, ITP, X28, X29, etc.) which in turn calls on the appropriate transport process (TCP, X25, UNIX, local-TTY). The User Command Decoder controls the establishment and termination of user sessions, and the consequent accounting and access control. It also decodes user commands. A session generally requires the collaboration of two PP's -- one to handle the "terminal" (user) side of the conversation, while the other handles the "host" (server) side; see Figure 5. Each PP is able to act in either role. A session is initiated when a user opens a "call" or "connection" to a terminal PP, which we will call "PP.term". PP.term makes a logical connection to the UCD, which starts a dialog with the user. The user will log in and request connection to a particular remote host using some protocol. The UCD will then [Page 16] UK/US Service at UCL IEN-185 request the appropriate host PP, "PP.host", to open the call to the selected server host. This mechanism is unsymmetrical with respect to the role of the two PP's. The User Command Decoder monitors the input from the terminal side, to detect and parse Protocol Converter commands. User messages generated as a result, and host output messages, are sent directly to PP.term. FIGURE 5. TYPICAL PROTOCOL CONVERTER SESSION ____________________________________________________ | | | User Command Decoder | | ____________ | | +-------> | | host input | | | | UCD |------> | | | <----| | | | | | | |____________| | | | | | | | | | | | | | | V <<Protocol V | | __________ Processes>> __________ | | | | | | | | | PP.term | <------------- | PP.host | | | | | host | | | | |..........| output |..........| | | | | | | V V | | Interface Interface | | to Transport to Transport | | Service Service | | | |____________________________________________________| This scheme using two PP's for each session is an attempt to avoid the combinatorics implied by five different terminal protocol handlers. It does have a cost, however -- we must design an internal protocol for communication between the PP's and with the UCD. The conversion function is effectively split into two parts, in each of the PP's. The internal protocol includes a flow control mechanism. No session can obtain more than its maximum share of the buffers, and if a PP stops writing data, back-pressure will soon stop the corresponding PP from reading new data for the same session. [Page 17] UK/US Service at UCL IEN-185 Each session has a guaranteed minimum number of buffers, so it can keep going, although perhaps slowly, when the system is congested. In the absence of congestion, the number of buffers in use by each session will fluctuate between this minimum and a maximum, depending upon the relative rates of input and output of data. As mentioned earlier, the Terminal Protocol Converter is being implemented in "C" and executed under MOS on LSI/11's. As shown in Figure 4, the Terminal Protocol Converter must include code for IP, TCP, Telnet, ITP, X28, X29, X25, as well as the UNIX driver, a command interpreter, and access control, monitoring, and accounting facilities. This code greatly exceeds the standard 16-bit address space of an LSI/11. At a later stage, we may use a virtual-memory MOS system on an PDP 11/23; at present, however, a much more straight-forward approach is being taken. The code is being split across three LSI/11s. The Transport Service Gateway and the IP Tunnel will also be contained in the same LSI/11s, since they share many modules. The Terminal Protocol Converter LSI/11s must be able to intercommunicate and to communicate with the UNIX system. In the early development of the service facility, we have been using 1822 interfaces for this purpose. However, as soon as the drivers are fully debugged, we will start using a local network -- specifically, a Cambridge Ring -- for these inter-LSI/11 links within the Terminal Protocol Converter. The Ring will similarly implement some of the other intra-UCL paths shown in Figures 1-3. To maximise our flexibility in assigning modules to particular LSI/11s, we defined a standard form for all transport (and network) services, including TCP and X25 [25]. This standardized interface, shown as a dotted line in Figure 5, is known at UCL as the "MOS Clean and Simple" interface. We then built an "Interprocessor Clean and Simple" (IPCS), which may be considered to be the software equivalent to an "extender board". IPCS allows the two sides of the interface to operate in different LSI/11s as if they were in the same LSI/11. IPCS itself has been implemented for LS/11's using either an 1822 connection or a low-level transport protocol on the Cambridge Ring. In assigning functions to LSI/11's, we have a number of constraints. Many of these are purely programming considerations, such as module pairs whose common interfaces requires both modules to be in the same processor. However, some constraints are imposed by the network protocols themeselves. [Page 18] UK/US Service at UCL IEN-185 In particular, the use of datagrams by IP is well suited to a distributed organization, but the problem appears harder with a virtual-call protocol like X25. For example, the SRI Port Expander multiplexes logical internet hosts onto a single host port, permitting the operation of TCP in multiple processors. However, there is no corresponding facility for X25. For example, the single PSS line must be attached to a particular processor, which then becomes THE "PSS access machine". 5. CONCLUSIONS This document has described the second-generation service facility under development at UCL, to connect the DARPA Catenet with X25-based networks in the UK. This facility is implemented as a complex set of protocol handling modules, operating an a set of inter-communicating LSI/11's. A local network, the Cambridge Ring, will be used for these interconnections. The operation and monitoring of this system will be performed by a program running under UNIX on a PDP/11-34. Linking the DARPA Catenet with public data networks has created important problems of access control, in addition to the familiar ones of addressing and routing. At the UCL end, we will force user login in order to apply access controls and distribute costs on a per-user basis. The complexity of the total systems leads to difficult problems of reliability. Further research will be necessary in this area. In the future, we intend to consider a generalisation of the present rather ad hoc distribution of functions in LSI/11's. The protocol conversions and network interconnections could be distributed into a pool of equivalent microprocessors, each performing a particular network or conversion function [21]. The Cambridge Ring would be used as a common communication bus for the processors. The intent would be to improve reliability and to more easily meet changing protocol requirements. [Page 19] UK/US Service at UCL IEN-185 6. REFERENCES [1] P. T. Kirstein, "Transatlantic Collaborative Computing". Indra Note 1027, UCL, London, December 1980. [2] P. T. Kirstein, "The Transition Requirements during 1981 for UK/US Services". Indra Note 1037, UCL, London, February 1981. [3] J. W. Burren, et. al., "Design for an SRC/NERC Computer Network", RL 77-0371A, Rutherford Laboratory, Abingdon, 1977. [4] C. F. Broomfield, "Packet Switching - The Experimental Packet Switched Service". Comp. Commun. Rev., 2, 7-11, 1975. [5] "ARPANET Protocols Handbook". NIC 7104, SRI International, Menlo Park, 1978. [6] J. B. Postel, "DOD Standard Transmission Control Protocol", RFC 761, USC Information Sciences Institute, Marina del Ray, 1979. [7] J. B. Postel, "DOD Standard Internet Protocol", RFC 760, USC Information Sciences Institute, Marina del Ray, 1979. [8] CCITT, "Recommendations X3, X25, X28, and X29 on Packet Switched Data Services". Int. Telecom. Union, Geneva 1978. [9] P. F. Linington, Ed., "A Network Independent Transport Service". SG3/CP(80)2, Post Office PSS User Forum, Study Group 3, The Computer Laboratory, Cambridge, England, February 1980. [10] (anon.), "A Network Independent File Transfer Protocol". FTP-B(80), Data Communication Protocols Unit, National Physical Laboratory, Teddington, February 1981. [11] I. M. Jacobs, et.al., "General Purpose Satellite Network". Proc. IEEE, 66, 11, 1448-1467, 1978. [12] P. T. F. Kelly, "Non-Voice Services - Future Plans". Proc. Conf. Business Telecommunications, Online, 65-82, 1980. [13] P. H. Masterman, "The RSRE Pilot Packet Switched Network". Proc. Intern. Conf. on Data Networks: [Page 20] UK/US Service at UCL IEN-185 Development and Use, London, pp 277-292, 1980. [14] "Character Terminal Protocols over PSS". PSS User Forum, Study Group 3, British Telecom, London, 1979. [15] P. M. Girard, "Protocols in the SRC/NERC Network". Issue No. 5, Rutherford Laboratory, September 1980. [16] C. J. Bennett, "A Simple NIFTP-Based Mail System". Indra Note 1025, UCL, London, January 1981. [17] C. J. Bennett, "TOPS20/TENEX NIFTP Overview Documenation". Indra Note 849, UCL, London, December, 1979. [18] C. J . Bennett, "Realization of the Yellow Book Transport Service Above TCP". IEN-154, UCL, London, July 1980. [19] C. J. Bennett, "The Yellow Book Transport Service: Principles and Status". IEN-155, UCL, London, August 1980. [20] A. S. Dunn, "A User Authorisation Scheme for SRCNET". Rutherford Laboratory, Abingdon, December 1981. [21] P. L. Higginson, "Plans for the Service Project". Indra Note 1007, UCL, London, November 1980. [22] P. L. Higginson, "Mapping Telnet to ITP". Indra Note 963, UCL, London, July 1980. [23] P. T. Kirstein, "The Facilities Needed in U.S. VAN Gateways to ARPANET at Different Levels". Indra Note 957, UCL, London, July 1980. [24] J. H. Haverty, "VAN Gateway: Some Routing and Performance Issues". IEN-181, Bolt, Beranek, and Newman, Inc., Cambridge, Mass., May 1981. [25] R. T. Braden and P. L. Higginson, "Clean and Simple Interface under MOS". Indra Note 1054, UCL, London, February 1981. [Page 21]